Method and device for generating distributed JAVA applications 
by means of a central XML configuration file 
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BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates to the generation of distributed applications in a multi 
tier or multi level environment, preferably in databases. It also relates to the 
generation of object oriented, distributed JAVA applications. 



DESCRIPTION OF THE PRIOR ART 

Distributed applications are further and more developed versions of typical Client — 
Server applications. The main advantage of such a distributed architecture, also 
known as n-tier or multi tier applications, is the clear separation of the individual 
15 layers (tiers). Those tiers are generally comprised of a database server for maintaining 
persistent data, an application server for executing an object logic or business logic, a 
WEB server for preparing the presentation and a Client Application for presentation 
to the user and user interaction. 



20 Such architecture is described in United States Patent 5,212,787. This document 
discloses a method for accessing a relational database outside an object-oriented 
environment, without exiting this environment. This access to the relational database 
is performed by a translator application for providing application protocol interfaces 
between the object-oriented environment and the relational database. 

25 

One problem with such architectures is the added complexity of the application 
developer has toconsider. In thq development process of a classical Client — Server 
application, the developer has a graphical development tool and directly accesses the 
database data. This simplifies the process because the developer has to consider only 
30 2 layers and not 3 or more. 



In many cases during the development of n-tier distributed applications, several types 
of Client applications are to be implemented. Typically one application is a fully- 
fledged JAVA Client with a Graphical User Interface (GUI) and the other is a slick 
35 WEB Browser based application. The data to process have to be sent to the WEB - or 



Application Server. When data have been sent to the WEB Server, they have to be 
processed — translated for the Application Server. The Application Server then 
executes the object logic or business logic and creates the statements to query the 
database. Due to the great complexity of the architecture, application developers are 
often puzzled and fail. 

It is therefore desirable to have a method and device to simplify the generation of 
applications in all tiers of a multi tier environment. 

SUMMARY OF THE INVENTION 

According to one aspect of the invention, a method is provided to generate 
applications in all tiers of a multi tier environment. The method comprises accessing 
an integrated configuration code comprising code sections for all information required 
for generating an application in each of the levels. The information comprises data, 
commands, definitions, layout and the like. The access can be implemented, for 
example, by receiving, retrieving, generating by user input, and re-working a 
previously stored integrated configuration code. In the configuration code all sections 
required for at least one application in at least one level of the multi-level 
environment are then parsed. The parsed code sections are extracted for the at least 
one level, and converted or translated into level-specific application code for each 
level. 

In an example embodiment of the present invention the method further comprises 
identifying all code sections required for at least one level of the multi-level 
environment in the integrated configuration code. 

In another example embodiment, the level-specific application code is JAVA code. 
The Java code provides a possibility to program an application independent of the 
actually used hardware, providing an application that can be run on nearly every 
server-, middle ware or client device in the tiers. So the generated application requires 
no additional information of the available application program interfaces or other 
proprietary characteristics of the devices for which the application is generated. 
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Therefore, the integrated configuration code can economize all device or platform 
specific information. 



Another example embodiment of the method further comprises sending or 
5 transmitting the level-specific applications to devices in the multi level environment. 

According to another aspect of the present invention, a method for generating an 
integrated configuration code is provided. The generation of the integrated 
configuration code comprises receiving at least one representation of a database table 

10 of a database. The at least one representation defines an object such as a business 
object in the database. This can be done, for example, by user input and the like. 
After that, all .meta-information of the at least one database table represented by the 
least one representation is retrieved fi*om the database in which the table is stored. 
The meta-information comprises information of the contents and additional 

15 information such as attributes and relations of the at least one database table. The 
meta information can comprise information about relations of the database table to 
other (even not listed) database tables. The tables and the meta information are used 
to generate an integrated configuration code. The integrated configuration code 
comprises code sections for all meta information retrieved from the database, which is 

20 required for generating an apphcation in each of the tiers. The configuration file 

comprises all information reqxiired to map the object defined by the representations of 
tables to the configuration file. The configuration file can be processed or revised to 
change and vary the relations and content of the object. The integrated configuration 
file defines the object and its masks, including the object logic (for example, business 

25 logic) like validation, presentation such as format, communication between the 

different tiers and the storage on the database. The components of the configuration 
file that can not be derived from the database, have to be generated from other 
previously generated configurations files, fi:om libraries or via user input. 
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In an example embodiment the integrated configuration code is an XML (Extensible 
Markup Language) file. By using an XML file the configuration code can be 
generated an4 processed independently of the actually used device. Another 
advantage is that XML provides a portable data and code format, which is easy to use. 
5 The integrated configuration XML file offers the possibility to code data such as the 
contents of an object and data objects together with program sections and 
configuration of the presentation of the object and data objects. 

The invention allows the developer to maintain all aspects in one place and to 
10 generate an implementation. The developer can create a skeleton multi tier 
application without programming effort, as the integrated configuration file is 
generated automatically. The developer can concentrate on the implementation of the 
application specific behavior by enhancing the generated skeleton provided by the 
XML configuration file. 

15 

The concept behind the invention is that every object, for example, a business object 
can be mapped to a database table. Therefore, it is also possible to describe this 
mapping in a configuration file. This is achieved according to one aspect of the 
invention by using a generator that takes one or more database tables as an argument 
20 and creates a base configuration file by reading the meta information from the 
database for the specified tables. 

The configuration file can also be used to configure the presentation of an object. In 
other words, it can be specified how to format the value of an Attribute, how to 
25 validate the value, what visual form and size the GUI component has (Textfield, 

Checkbox, Dropdown, Menu...). Furthermore it is possible to specify labels and other 
aspects in the configuration file without actually programming in JAVA. All this 
information describes an entity, which is in fact the blue print to dissolve or 
disintegrate an object. 

30 

The invention uses and leverages the following technologies: JAVA, XML and JSP 
(Struts). 
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Java is an object-oriented and platform independent program language, used for the 
generated applications. SWING is a graphical user interface class library, such as 
ATW for generating user interfaces in a Java environment, instead of using SWING 
5 any other standard GUI library like ATW can be used for generating the GUIs of 

applications. JDBC (Java Database Connectivity) is a Java- API (AppUcation program 
interface) for executing of SQL (Structured Query Language) orders used in relational 
databases. JDBC can be utilized in every application having direct access to a SQL 
database. XML (Extensible Markup Language) is used for the configuration file. The 
10 extensibility of XML enables storage of data and XML provides Parsers, DTD 

(Document Type Definition) to convert the XML file to JAVA applications. JAVA 
Server Pages (JSP) is used to generate GUIs for Internet and HTML applications. 
The JSPs can, for example, be generated with STRUTS, an open source framework of 
utilizing pre-stored design patterns to facilitate the development of JSP applications. 

15 

When the developer finally has specified all needed information for an entity, the 
necessary code 1 5 files can be generated. 

The resulting files per Entity are: 
20 1 . Java Class Source files 

• Swing Panel 

• Swing Table 

• Client Object 

• Server Object 

25 • Data object of the Object Logic 

• Struts Action 

• Struts Form 

2. JSP (Java Server Pages) Pages 

• Presentation of the Object 

30 
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According to yet another aspect of the invention, a software tool is provided 
comprising program 30 code means for carrying out the method of the preceding 
description when the program product is run on a computer or a network device. 

5 According to another aspect of the present invention, a computer program product 
downloadable from a server for carrying out the method of the preceding description 
is provided, which comprises program code means for performing all of the steps of 
the preceding description when the program is run on a computer or a network device, 

10 According to yet another aspect of the invention, a computer program product is 

provided comprising program code means stored on a computer readable medium for 
carrying out the methods of the preceding description, when the program product is 
run on a computer or a network device. 

1 5 According to yet another aspect, the present invention provides a computer device for 
generating distributed applications for each level in a multi-tier environment. The 
computer device comprises a reception module, a controller, a user interface and a 
network module. The reception module is required, to receive an integrated 
configuration code comprising code sections for different levels of a multi level 

20 environment. The controller, is connected to the reception module, and is configured 
to parse, identify, extract and convert code sections of the integrated configuration 
code into level-specific application code for each tier in the environment. The user 
interface is connected to the controller, to extend and revise said integrated 
configuration code. The network module is connected to the controller, to transfer the 

25 generated level-specific application code to other devices in a network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In the following, the invention will be described in detail by referring to the enclosed 
drawings in which: 

30 
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Figure 1 is a block diagram depicting a multi tier environment; 

Figure 2 is a block diagram, depicting an example of the generation of an XML 
configuration file; 

5 

Figure 3 is a simple example for the mapping of database information to an XML file; 
Figure 4 is an example of XML entity configuration file; 
10 Figure 5 is an example of XML attributes configuration file; 
Figure 6 is an example of XML relation configuration file; 

Figure 7 is a block diagram, depicting an example of the generation of applications in 
15 a multi tier environment form of an XML configuration file; 

Figure 8 is an example of a swing screen implementation of a business object; 

Figure 9 is an example of a swing table implementation of a table; 

20 

Figure 10 is an example of an implementation for validation and notification of 
interactions with a business object; 

Figure 1 1 is an example of an implementation for holding the data of a business 
25 object; 

Figure 12 is an example of an implementation of a hook to execute a server side 
business logic of a business object; 

30 Figure 13 is block diagram, depicting an example of the bindings between a graphical 
user interface and data; 
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Figures 14 to 17 describe an example of a synchronization process of data objects 
between a client and a server; and 

Figures 1 8 to 22 are examples of properties for the different properties of the code 
5 used in the aforementioned generation processes 

In other instances, detailed descriptions of well-known methods, interfaces, devices, 
and signaling techniques are omitted so as not to obscure the description. 

1 0 DETAILED DESCRIPTION OF THE INVENTION 

Figure 1 is a block diagram depicting an overview of the typical multi tier 
environment architecture. Distributed applications are further and more developed 
versions of tj^ical Client — Server Applications. The main advantage of such a 
distributed architecture also known as n-tier or multi tier applications is the clear 

15 separations of the individual layers (tiers). The depicted multi level or multi tier 
environment is comprised of a Database Server 2, an Application server 4, a Client 
Application 6, a Web Server 8 and a HTML (Hypertext Markup Language) Client 10. 
The Database Server 2 represents the first or lowest tier of the multi tier environment. 
The Database Server 2 is for maintaining persistent data, and physically stores the 

20 data of a database in a form of tables, entries, attributes, relations and other meta 

information. The Database Server utilizes a database server application to retrieve the 
physically stored data and to exchange data with the Application Server 4. 

The Application Server 4 forms the second tier of the environment. The Application 
25 Server 4 forms the link between Database server 2 and the Client Application 6 and 
the Web Server 8 respectively. The Application Server 4 is for executing an object 
logic or business logic, and generates queries to query the data stored in the Database 
Server 2 according to requests received from the Client 6 and the Web Sewer 8. The 
requests can comprise read out operations to retrieve information stored in the 
30 database or write operations to change the content of the database. To execute the 
read out operations, the Application Server 4 comprises a query builder application 
and a data object updater to execute write operations corresponding to requests 
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received jfrom the Client 6 or the Web Sewer 8. To execute the communication and to 
handle the different protocols between the Database Server 2, the Web Server 8 and 
the Client 6, the Application Server 4 uses an application server application. 

5 Client 6 is connected to the Application Server 4 to send data object requests to and to 
update data objects in the Database Server 2. The Client 6 forms the third tier. The 
Client 6 comprises a graphical user interface (GUI) for presentation and user 
interaction to simplify the database access. The GUI and the data exchange with the 
Application Server 4, is executed by means of a client application running on a user 
10 terminal. 

The Web server 8 is connected to the Application Server 4 to exchange data object 
requests and data objects between the Database Server 2 and the HTML Client 10. 
The Web Sewer 8 is for preparing presentations and forms the fourth tier in the 
1 5 environment. The Web server 8 comprises a data object updater and a data request 
executor to interpret the different protocols and to forward requests between the 
HTML Client 10 and the Application Server 4. The data exchange and the 
interpreting are executed by means of a web server application. 

20 The HTML Client 10 is connected to the Web server 8 to exchange data and to 

provide database access via the Web. The HTML Client 10 forms the fifth tier in the 
environment. The HTML Client 10 transforms the HTML code received from the 
Web Sewer 8 to a web page as a graphical user interface for presentation and user 
interaction. The web page has to be defined as a HTML graphic application. 

25 

To provide all these applications, the database server application, the application 
server application, the client application, the web server application and the HTML 
graphic application has to be generated. The application developer has to consider the 
problem of high complexity. 

30 

In many cases during the development of n-tier distributed applications, several types 
of Client applications have to be implemented. Typically one application is a full- 
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fledged JAVA Client (Client 6) with a GUI and the other is a slick WEB Browser 
based application (Web Server 8). The data to be processed have to be sent to the 
WEB 8 - or Application Server 4. When data has been sent to the WEB Server 8, 
they have to be processed — translated for the Application Server 4. The Application 
5 Server 4 then executes the object logic or the business logic and creates the statements 
to query the database Server 2. Due to the great complexity of the architecture, even 
small errors lead to failures in the interaction between the different tiers. 

Figure 2 is a block diagram, depicting an example of the generation of an XML 
10 configuration file 26. The method basically comprises two more or less independent 
sub-elements, the generation of the applications form a fully integrated configuration 
code, and the generation of the configuration code is by means of meta information of 
a database and the application specific requirements. The latter is depicted and 
described in figiire 2. Both sub methods contribute to simplify the generation of 
1 5 applications in a multi tier environment. 

To generate a fully integrated configuration file 26 for generating distributed JAVA 
applications for interacting with databases in a multi-tier environment having at least 
a server tier and a client tier, the properties of an object or a business object have to be 

20 fixed. A relational database determining the tables 20 comprising the required 

information can do this. Having determined the tables 20 comprising the relevant 
information, the respective relations between the tables can be retrieved from the 
database 24 comprising this information. If the applications to be generated are 
designed to access existing tables of a database, it can be sufficient to determine the 

25 required tables, for example, in a list of tables 20. Additional information, such as 
data structure, can also be retrieved from the database 24. Altematively, only single 
table elements and the respective relations can be determined, to generate, for 
example, a demo version for the application. 

30 Based on the tables and the meta information, a configuration file 26 is provided by 
generator 22. The configuration file 26 can be generated as an XML configuration 
file comprising all information for the desired application. Thereby a selection of 
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database tables or the representations of these tables and the respective relations 
defining a database or business object can be mapped to a configuration file. 
Additional information according to the number of expected or required tiers can also 
be determined prior to the generation of the configuration file. 

5 

The basic concept is to define all properties in an integrated file, and generate a single 
composition with all information necessary to generate applications in all tiers of the 
environment. So not only the single properties necessary for a single application is 
defined, but also the whole structure of the single tiers are integrated in a single file. 
1 0 Basically the concept can be compared to the generation of a single part of a jigsaw 
puzzle by first generating a picture and cutting only the required piece from it, 
wherein it is guaranteed that all parts cut fi-om the same picture fit,instead of 
generating a single part separately and hoping that there is somewhere another part 
going together. 

15 

Upon passing a list of table names 20 to the entities generator 22, the generator 
creates a default configuration file 26 (entities.xml), with the information retrieved 
from the database 24. To generate the integrated configuration file, the application 
uses XML- technology such as a Parser and DTD (Document Type Definition). 

20 

Figure 3 depicts a simple example for mapping of a database table to an XML file. 
The generation can be embodied as a translator translating the tables of, for example, 
an ODBC- or an ORACLE, or Trans-Base- database with its structure and contents to 
an XML file. 

25 

Starting from a simple database table 30, the entries of the table are mapped to an 
XML configuration file 30. The present example only describes the structure and the 
contents of the table without any relationships between the single elements. It should 
be noted that the present example is not restricted to price lists, but can also be 
30 applied to any kind of table contents, such as part tables and the like. This example is 
only for providing an example of how to implement one aspect of the integrated file 
generator. According to the XML design rules, the name of the list forms the start 
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<price list> and the end </price list> of the XML file section. The other properties are 
also forming sub-elements with additional information about the contents of the list. 
Due to the relatively small number of elements in the table, the mapping function 
between the table and selected table elements should be clear, and provide a sufficient 
5 indication of how to implement the configuration file generator. The exact 

implementation of the generator is dependent on the database structure, the operation 
system and the computer language which are used to implement the generator. 

Figure 4 is an example of an XML entity configuration file section of an integrated 
10 configuration file. Entities are used to define objects or business objects of the same 
type. The entity configuration file (entities.xml) comprises an XML tag "<entity" to 
relate the meaning of the following text to entities. 

The tag is not closed to indicate that the depicted selection is only exemplary and is 
1 5 not limited to the depicted text. The enclosed list defines the properties of an entity, 
defining a name, a label and a comment of the object. The entity is further defined by 
Boolean class name, a document class name, a condition possible condition errors, a 
signed as primary key and unique key. 

20 Figure 5 is an example of an XML attributes configuration file. Attributes define the 
properties of an object or a business object. As in the description of Figures 3 and 4, 
the file section starts with an XML tag 50 "<attributes>" identifying the following 
text as attributes. The first attribute relates the label "Deal id" to the name 
'DEALID". In the following, the class name, the format and the maximum number of 

25 digits of the entity is defined. The next attribute tag defines the attributes of the entity 
"inspection date". 

Figure 6 is an example of an XML relation configuration file. Relations indicated by 
the XML tag 60 "<relation>" express the joins when storing or loading objects or 
30 business objects. In the figure, the entity "CONTRACT" with the name 

"dealcontract" is allocated to the parent attribute "DEALID". Similarly, the entity 



"PARTNER" with the name "dealpartner" is allocated to the parent attribute 
"DEALID'. Other attribute types are descriptors, identificators, optional 
descriptors and other functionality can also be defined or fixed. 

5 The entities, the attributes and the relations can be extracted from the meta 

information which are stored in the database. The configuration file itself can be 
automatically generated, if only the database tables are determined, and the respective 
meta information is retrieved from the database. 

10 Figure 7 is a block diagram, depicting an example of the generation of applications in 
a multi tier environment to form an XML configuration file. As discussed in Figvire 
2, the method basically comprises two more or less independent sub-elements, the 
generation of the applications form a fully integrated configuration code, and the 
generation of the configuration code is by means of meta information of a database 

15 and the application specific requirements. The former method is depicted and 
described in Figure 7. 

With the entity and attribute and relation information defined in the XML 
configuration file 70, the framework 71 generates base classes for the applications in 
20 all tiers of the multi tier environment. On the Client side 72, the applications for 
objects or business objects 73 and for screens and tables 75 are generated. On the 
server side 73, applications for objects or business objects 77 and for the entity 
manager storage 78 are generated. The generator 71 also generates middleware 
applications for data objects 76. 

25 

The generation of the application can use an extended version of JAXB (Java 
Architecture for XML binding) to map the XML elements to classes in the Java 
programming language. Standard JAXB is not capable of identifying the relevant 
section in the XML file necessary for the single applications in each tier. Therefore it 
30 is necessary to provide an additional feature or tool to parse, identify and extract, the 
relevant code sections in the XML file prior to the generation of the Java applications. 
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The basic concept is to generate a single composition with all information necessary 
to generate applications in all tiers of the environment. Basically, the concept can be 
compared to the generation of a jigsaw puzzle by first generating a picture and cutting 
it into pieces, wherein it is guaranteed that all parts are fitting, instead of generating 
5 each part separately and hoping that they would go together. 

Figxare 8 is an example of a swing screen implementation of a business object. The 
swing screen implementation is provided as an exemplary gridbag layout, binding 
visual components with data to the corresponding objects or business objects. 

10 SWING is a graphical user interface class library, such as ATW for generating user 
interfaces, instead of using SWING any other standard GUI library like ATW can be 
used for generating the GUIs of applications. The client interprets the depicted swing 
screen to display a protected void for user input and to retrieve the initiation date of 
the object deal following to the input on the input of an object identification (dealid). 

15 All the depicted code section of the swing screen example can be directly generated 
fi-om the XML configuration file. 

Figure 9 is an example of the implementation of a database table as a swing table 
code. With default renderers and editors, columns are defined as (non-) sortable, 
20 editable, (non-) resizable, preferred- min- max number of characters and the like. All 
the depicted code section of the swing table example can be directly generated from 
the XML configuration file. 

Figiare 10 is an example of an implementation for validation and notification of 
25 interactions with an object or a business object. Object or business objects for Client 
side validation, register listeners to be notified if the object or business object has 
changed. 

Figure 1 1 is an example of an implementation for holding the data of an object or a 
30 business object. Data objects for holding the data of an object or a business object 
will be sent to the Server if modified. The swing implementation has some help 
methods like "isModified0". Figure 12 is an example of an implementation of a hook 
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to execute a server side object logic or business logic of an object or a business object. 
It is provided by static methods without any state. 

Figure 1 3 is block diagram, depicting an example of the bindings between a graphical 
5 user interface and data. The block diagram demonstrates how data of an object or a 
business object interacts with the presentation layer. This is done using the MVC 
(Model, View, Controller) Pattem, which was implemented by the code generator 
when the panel was generated. 

10 The depicted graphical user interface (GUI) 130 comprises different components for 
receiving user input and displaying data. Each of the input components is registered 
by an adapter 132 to respective listeners. In case of a user input to the receiving 
components of the GUI 130, the adapter gets the value from the component and 
delegates it to the object or the business object 134. The object 134 runs through all 

15 its registered listeners to execute a changed event. The changed event is received by 
adapter controller 136 which in tum controls a component to display in the GUI 130 a 
formatted value according to an attribute which is bound to the control. 

Figures 14 to 17 describe an example of a synchronization process of data objects 
20 between a client and a server. 

Figure 14 depicts an object 140 with data objects changed by a Client. The client 
application extracts the changed or modified data objects 142 from the Object 140 and 
sends the extracted modified data objects 142 to the server. 

25 

Figure 1 5 depicts the reaction of the server to the reception of the modified data 
objects. Each received modified data object 1 50 is first assigned 1 5 1 to a database 
table 1 55, to determine if the data object is assignable and if the value of the data 
object has changed. When update action 152 is executed, the update action comprises 
30 the updating of persistent data in storage and in table 155. To confirm the update, the 
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changed data are a read out 154 from the storage, and the updated data objects are 
returned to the client 

Figure 16 depicts the reaction of the client to the reception of the updated data objects 
5 162 from the server. Updating the data objects 162 in the tables of the object 160 
performs the updating. 

Figure 17 depicts the reaction of the client to the updated object 172. The updated 
objects 172 are used to update the GUI components 170 on a display of the Client. 
10 Following the updating process, all data objects (the updated and the unchanged data 
objects) specified by the GUI and the object are displayed. The updating of the GUI 
component 170 is executed by using listener and adapter applications. 

All the above applications necessary to provide the interactions between the Client 
15 and the Server can be generated from a single XML file specifying the object itself, 
the GUI the Extract and update processes and the properties of the data objects. In 
summary, Figures 14-17 demonstrate how data from one or more Clients are 
synchronized with the database without having to write specific code by the 
application developer. 

20 

Figures 18 to 22 are examples of properties for the different properties of the code 
used in the aforementioned generation processes. 

Figure 18 describes properties for entities, such as names, labels and comments for an 
25 entity. Other properties are related to type and handling of the entity, the type of data, 
the language with which the entity has to be interpreted, a condition for an error 
message, an object class name, a data object class name, the type of access to be 
granted to a list of attributes in the entity. 

30 Figure 19 describes database relevant properties for entities. Such database relevant 
properties are names for a schema, a write and read table, primary keys, and 
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statements for generating a primary key, and to search, select, update, delete and 
insert data objects in the database. 

Figure 20 describes a selection of properties for attributes. 

5 

Figure 21 describes GUI relevant properties for attributes. The GUI relevant 
attributes are used to arrange data in or as a texfield, a label, a check box, an icon, a 
code table, etc. Tabled depicted in the GUI can be arranged by defining the number 
of rows and columns, and a code table name can be used to name a table. 

10 

Figure 22 describes relationships between entities. The name of a relation and the 
Entity Name should be clear to describe the relation itself and the entities associated 
by the relation. The foreignkeys are used to define the keys to join the entities. The 
foreignkeys are used to implement the different relationships in the meta information 
15 of the database in the configuration file. In Figure 6 only the relation "parent 

attribute" is shown, but other relations can also be defined as 1 : 1 , 1 :n or n:m relations, 
optional and restricted relations and relation between one two or more tables. 

This application contains the description of implementations and embodiments of the 
20 present invention with the help of examples. It will be appreciated by a person skilled 
in the art that the present invention is not restricted to details of the embodiments 
presented above, and that the invention can also be implemented in another form 
vdthout deviating fi:om the characteristics of the invention. The embodiments 
presented above should be considered illustrative, but not restricting. Thus the 
25 possibilities of implementing and using the invention are only restricted by the 
enclosed cMms. Consequently various options of implementing the invention as 
determined by the claims, including equivalent implementations, also belong to the 
scope of the invention. 
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